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(57) Abstract 

A billing system creating the opportunity to generate new types of price lists for provision of telecommunication services, making it 
possible to develop entirely new services with entirely new service structures. The system comprises means for receiving an SDR (Service 
Detail Record), sending said SDR to a service pricing scheduler where a Service Usage Module comprised in the SDR is associated with 
a price list to which the customer has agreed. The price is sent back with a Service Pricing Module associated with said Service Usage 
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Improvements in, or Relating to. Telecommunication s Systems 

The present invention relates to billing systems for use with 
telecommunications systems, especially telecommunications systems adapted to 
provide infocom. telecommunications system incorporating such billing system, 
and methods of costing infocom usage in telecommunications systems and billing 
for such usage. 

At the present time, telecommunications systems employ billing chains 
based on national number plans and conventional base telephony, where charges 
are determined by the geographical distance over which a call is transmitted and 
the time for which a call is connected. The ability to base telecommunications 
charges on usage of IN-based services is limited by the fact that substantial parts 
of the pricing information generated by these systems is stripped out. This occurs 
during the normalisation which takes place because the billing chain uses a call 
record with a fixed length and fixed structure. Information that is service-related 
does not appear in the call record. 

The fixed length format runs counter to the requirements for renewal and 
supplementation which is imposed, by modern information services, on the billing 
chain. At the present time, service based charging is b?sed en "fixec", or r.o 
solution is provided. 

Typically, existing billing systems are based on a collection system which 
gathers TT records from Ax stations and IN nodes with a periodicity of once per 
hour to once per day. The TT records are normalised to a call record with a fixed 
length which is base-priced. After one day, the call records are delivered to the 
system wnich is to place them with the correct invoicing system. This takes 
another day. It is only after two days that the invoicing systems can start 
processing the information in the call records. 



In summary the deficiencies of current billing systems are: 
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limitation to conventional base telephony (time and distance); 

limited national number plans; 

loss of important information; 

inability to charge for service functions; and 

inability to provide pricing details in real time. 

in modem IN based telecommunications systems, entry of customer data 
.s performed by a large number of support systems which administer the different 
organisational units of the telecommunications system. This results in some 
overlap of information and introduces a very substantial risk of faults and 
.nconsistencies. To enable a customer to use a telecommunication service three 
types of customer data need to be entered: 



a description of the customer" s network, i.e. company exchanges 
directly connected telephones, modems, and fax machines, that 
form part of the customer's network; 

number plans, short-cut numbers, functions and call answer 
messages selected by the customer; and 

billing information which reflects the customer's organisational 
structure so that he can be invoiced as required. 

Ideally, customer information should be fed in via a central system which 
d.stributes information to the administrative systems and service producing 
elements used to produce the service. It is important, however that the customer 
h,mse.f should have the opportunity to interact with his own services i e via the 
Internet. Customer cata shou.d. therefore, be handled by a central customer care 
system which: 
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provides a unified input of customer data to a single place in a 
telecommunication's production apparatus; 

permits the fast introduction of new services; 

permits the fast extension and modification of existing services; 

provides service surveillance; and 

provides customer management facilities. 

The billing system of the present invention creates the opportunity to 
generate new types of price list for the provision of telecommunications services. 
This in turn makes it possible to develop entirely new services with entirely new 
service stnjctures. Thus, the price plans used today can be superseded by price 
lists in the flexible billing concept of the present invention. 

In the present invention the pricing of a service is divided into a number of 
stages, namely: 

the service provides information, on what the customer has done, 
to a SDR (Service Detail Record).; 

a billing system handler, or SDR subscription service, receives a 
SDR and sends it to a service pricing scheduler; 

the service pricing scheduler picks out a Service Usage Module, 
described later in this specification, in the SDR and. depending on 
the customer ID specified in the respective module, associates the 
module with a price list to which the customer has agreed. 

the pnce list system packs up the Service Usage Module and 
analyses what is to be priced; 
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the price is calculated and entered in a Service Pricing Module; 

the Service Pricing Module is coupled with the Service Usage 
Module and returned to the pricing scheduler; 

the pricing scheduler associates all Sen/ice Usage Modules with 
their Service Pricing Modules and returns the priced SDR to the 
billing system handler; and 

the billing system handler sends priced SDRs to a SDR archive, or 
store, for intermediate storage until a post-processing system, e.g. 
an invoicing system, collects it. 

The pricing scheduler is service-unique. One pricing scheduler may price 
each individual SDR per se, whereas another may assemble a number of SDRs, 
for one session, before calculating the price. This entirely depends on the way in 
which the service produces SDRs and how the service is priced. 

Some pricing schedulers may assemble, in themselves, a number of SDRs, 
before sending the information to the price list system. 

A customer can be handled either as *n individual customer, o, as one 
belonging to a customer group. All customers belong to a marketing company. 
A service can be marketed by one. or more, marketing companies. 

A defined basic price list forms the basis of all price lists in the service. It 
specifies no prices, but represents a skeleton on the basis of which all other price 
lists are based. 



Each marketing company has its own price lists. These are of the following 

types: 



base pnce list; 
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customer group price list; and 

customer-unique price list 

The base price list contains the basic underlying price list for the service 
within a specific market. The base price list is independent of the customer and 
the time when the service is used. The base price list may be the price list to 
which the vast bulk of customers are connected. There is only one base price list. 

The customer group price list is a type of price list containing a special 
pricing for a specific customer group. The number of customer group price lists 
depends on the customer groups defined. Customer grouping is a way of offering, 
the vast bulk of customers, customer-unique pricing without being overwhelmed 
by a mass of different price lists. 



The customer-unique price list is a type of price list produced for a specific 
customer. This price list is thus the actual customer adaptation. It is available for 
important customers, or customers who. for some reason, cannot be linked to any 
15 customer group. 

Some price lists are in actual fact a list of prices, whereas others are based 
on algorithms, or functions, from which actual prices are calculated Th e simplest 
form of price list merely tabulates prices. 

1 

A complex price list system assembles all SDRs relating to one session 
20 before it calculates a mass of prices. 

The customer is involved in all pricing cases. This does not mean that a 
user is always involved, since services may act autonomously. 

The costs c* one session can be shared by different customers. The A- 
and B-sides have c "erent access forms. 



25 



Consider sc~e basic pricr.g cases: 
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1 • "A" communicates with "B", e.g. connection via the PSTN. 

2. "A- accesses a service and. via this service, communicates with "B" e g 
cans from GSM to VCC. which, in a queuing system, makes an onward 
connection to the PSTN. 

3. -A- accesses a service. e.g. listens to his mobile answering system via the 
PSTN. 



4. The service communicates with "B", e.g. provides an output from a Multifax 
service. 



5. The service performs a function not involving any communication e g 
holds uncollected faxes for an extended storage period. 

6. The service communicates with another service, e.g. VCC uses the tele 
answering service. 

The present invention can readily cope with all these pricing cases, and is 
sufficiently flexible to cope with many other pricing cases as well. 

According to a first aspect of the present invention, there is provided a 
telecommunications billing system, for use with a telecommunications system 
comprising: 

an information services network containing a plurality of service 
producing elements; and 

a communication services network containing: 
a plurality of service switching elements; 



a signalling network; and 
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a transport network; 

said telecommunications system being adapted to provide infocom services to 
customers and said billing system being adapted to provide flexible pricing and 
billing for usage of infocom services, characterised in that said billing system 
.ndudes handler means for receiving SDRs generated by said service producing 
elements and transmitting said SDRs to a service pricing schedu.er means in that 
sard SDRs include Service Usage Modu.es. in that said service pricing scheduler 
means is adapted to associate a Service Usage Module with a price list 
appropriate thereto, and in that pricing means are provided for calculating a price 
associated with a Service Usage Module and inserting said price in a Service 
Pncng Module associated with said Service Usage Module. 

After insertion of a price in a Service Pricing Module, said pricing scheduler 
means may be adapted to return a priced SDR to said handler means. 

Said handler means may be adapted to transmit priced SDRs to a SDR 
archrve means adapted to store said priced SDRs until they are transmitted to a 
post-processing system. 

A service use session may generate one. or more SDRs. 

Service Pricing Modules may be added to SDRs. only after an SDR has 
been priced. 

Each SDR may be a collection of tagged data items describing a service 
use session. 



An SDR-s size and content may vary in accordance with an infocom service 
to which it relates. 



Tagged data .terns in an SDR may be encoded using the BER for A3N.1. 
Related tagged data items in an SDR may be grouped into service 
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modules. 



A particular set of related tagged data items in an SDR may be grouped 
into one of the following four types of service module: 

a Service Header Module, which contains tagged data items 
associated with a SDR as a whole; 

a Network Service Module, which contains tagged data items 
related to consumption of network capacity by a particular service 
use session; 

a Service Usage Module, which contains tagged data items relating 
to sen/ice usage; and 

a Service Pricing Module which contains tagged data items relating 
to pricing of an infocom service. 

An SDR may contain: 

one. or more, Network Usage Modules; and 

one. or more. Service Usage Modules. 

An SDR may contain a session identifier and a sequence number to enable 
a post-processing system to recover a chronological order in which SDRs were 
produced during a service use case. 

An SDR may contain at least the following tagged data items: 



an identity of a customer; 



an identity of a marketing company: 
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an identity of a service to which the SDR relates: 
and an SDR may contain one, or more of the following tagged data items: 
an access form; 
a time: 
a date; 

an identity of a user; 
a connection identity; 
an operator; 
a service provider; 
a customer price; and 
a market price. 

Relationships between service modules within an SDR may be governed 
by data items referred to as NSM/SUM correlators and SUM/SPM correlators, and 
these data items may have unique values within an SDR. 

Said billing system may include one, or more, price lists, and said pricing 
system may be adapted to implement price list definitions, identify price lists to 
which an SDR relates and thereby produce priced SDRs. 

Said pricing scheduler means may include said pricing system and may be 
adapted to receive SDRs. analyse SDRs and identify price lists appropriate to an 
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Said pricing scheduler means may be service independent, and anything 
which is service, customer, or market unique, may be incorporated in price lists. 

Each infocom service may have a unique pricing scheduler means 
associated therewith. 

Said pricing scheduler means may be adapted to assemble a plurality of 
SDRs before said SDRs are priced. 

Said pricing scheduler means may be adapted to price individual SDRs. 

Customers may be handled, for pricing purposes, as individual customers, 
or as members of a customer group. 

All price lists may be based on a basic price list. 

Price lists may be of one of the following types: 

a base price list which is independent of customer and time of use 
of an infocom service; 

a customer group price list, applicable *o a group of customs,*; and 

a customer unique price list applicable to a single customer. 

Price lists may be either lists of prices, or algorithms/functions for 
calculating prices. 

SDRs may be generated independently of any action performed by a 
customer. 



Costs for a service use session may be shared between different 
customers. 
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Said billing system may include fault handling means adapted to process 
faulty SDRs. 

Said billing system may be adapted to operate with infocom services 
having plural functions. 

Said information services network may be an IN having a data server. 

Means may be provided to label an SDR as erroneous, if a price list relating 
to an SDR cannot be identified. 

According to a second aspect of the present invention, there is provided. 
In a telecommunications system comprising: an information services network 
containing a plurality of service producing elements; and a communication services 
network containing a plurality of service switching elements, a signalling network 
and a transport network, said telecommunications network being adapted to 
provide infocom services to customers, a method of pricing usage of infocom 
services in a flexible manner, characterised by the steps of: 

each service producing element, (SPE). generating SDRs; 

collecting said SDRs at a handling means, said SDRs including ? 
Service Usage Module; 

associating each Service Usage Module with a price list; and 

determining a price to be associated with each Service Usage 
Module and adding said price to the SDR. containing said Service 
Usage Module, in the form of a Service Pricing Module. 



Priced SDRs may be returned to a handler 



means. 



Priced SDRs may be transmitted to a SDR archive means and stored 
therein until collectec by a post processing system. 
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Said post processing system may be an invoicing system. 
A service use session may generate one. or more SDRs. 

Service Pricing Modules may be added to SDRs. only after an SDR has 
been priced. 



Each SDR may be a collection of tagged data items describing a service 
use session. 



An SDR's size and content may vary in accordance with an infocom service 
to which it relates. 



Tagged data items in an SDR may be encoded according to the BER for 

ASN.1. 



Related tagged data items in an SDR may be grouped into service 
modules. 



A particular set of related tagged data items in an SDR may be grouped 
into one of the following four types of service module: 

a. Service Header Module, which contains tagged data items 
associated with SDR as a whole; 

a Network Service Module, which contains tagged data items 
related to consumption of network capacity by a particular service 
use session; 

a Service Usage Module, which contains tagged data items relating 
to service usage; and 



a Service Pricing Module which contains tagged data items relating 
to pricing of infocom service. 
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An SDR may contain: 

one, or more, Network Usage Modules; and 

one, or more, Service Usage Modules. 

An SDR may contain a session identifier and a sequence number to 
enable a postprocessing systems to recover a chronological order in which SDRs 
were produced during a service usage case. 

An SDR may contain at least the following tagged data items: 
an identity of a customer; 
an identity of a marketing company; 
an identity of a service to which the SDR relates;; 
and an SDR may contain one, or more, of the following tagged data items 
an access form; 
a time; 
a date; 

an identity of a user, 
a connection identity; 
an operator; 
a service provider; 
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a customer price; and 



a market price. 



An SDR may include data items referred to as NSM/SUM correlators and 
SUM/SPM correlators which govern relationships between service modules in the 
SDR. and the values of these data items may be unique within an SDR. 

Said billing system may include one, or more, price lists, and said billing 
system may be adapted to implement price list definitions, identify price lists to 
which an SDR relates and thereby produce priced SDRs. 
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A pricing scheduler means may be adapted to receive SDRs. analyse 
SDRs and identify price lists appropriate to an SDR. 



A plurality of SDRs may be assembled before pricing. 
All price lists may be based on a basic price list. 
Price lists may be one of the following types: 
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a base price list which is independent of customer and tim» of us 
of service); 



a customer group price list, applicable to a group of customers; and 

a customer unique price list applicable to a single customer. 

Price lists may be either lists of prices, or algorithms/functions for 
calculating prices. 
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According to a third aspect of the present invention, there is provided a 
telecommunications system, characterised in that said telecommunications system 
includes a billing system, as described in any preceding paragraph, or in that said 
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telecommunications system is adapted to price telecommunications service and 
network usage using a method as described in any preceding. 

Said post-processing system may be an invoice system. 

SDRs may be moved from service producing element, to pricing scheduler 



SDRs may be used for any of the following functions: 

billing, both inside and outside a telecommunication operator's own 
organisation; 

consolidated billing; 

production of reports and statistics; 

quality assurance; and 

service management, including identification of fraud, churning, 
abnormal traffic loads, failure rates and technical malfunctions. 

Post-processing systems, requiring access to information contained in 
SDRs, may subscribe to said handler means. 

Said system may have a single invoice printing function. 

Said pricing scheduler means may handle pricing of traffic rates and 
service events, and pricing related to periodical charges, subscription charges and 
discounts may be handled by post processing systems. 



5 



means, to an invoicing system. 
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Each post-processing system subscribes to SDRs from one, or more 
infocom services, and/or to selected data items from within an SDR. 



WO 99/09733 PCT/SE98/0137O 

- 16 - 

Post-processing systems may collect SDRs. at predetermined intervals 
from a SDR archive, and/or post-processing systems may be alerted when SDRs 
are available for collection in a SDR archive. 

At least some infocom service producing elements may issue SDRs as a 
request for pricing information, which SDRs are passed to pricing scheduler 
means, priced and returned to said service producing elements. 

SDRs without a subscribing post-processing entity may be discarded while 
SDRs having a subscribing post-processing entity may be retained for a period of 
time in a SDR archive. 

Embodiments of the invention will now be described, by way of example, 
with reference to the accompanying drawings, in which: 

Figure 1 illustrates, in schematic form, an overview of a flexible billing 
system according to the present invention. 

Figure 2 illustrates, in schematic form, the architecture of a flexible billing 
system, according to the present invention. 

Figure 3 illustrates, in schematic form, the development of a service 
employing the flexible billing system of the present invention. 

Figure 4 illustrates the relationship between price lists in the present 
invention. 

Figure 5 illustrates the basic structure of tagged data items. 
Figure 6 illustrates the sen/ice module structure of an SDR. 



Figure 7 illustrates the structure within the service usage module of Figure 

6. 
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Figure 8 illustrates the structure within the service module of Figure 6. 

Figure 9 illustrates the relationship between service modules in an SDR. 

Figure 10 illustrates that a service use session may include events within 
a single service, or within several services co-operating in sequence, or 
parallel. 

Figure 1 1 illustrates how the number of SDRs produced by a service use 
session depends on the type of service, or co-operating services. 

Figure 12 illustrates how a service usage module may contain one, or 
several related service events. 

Figure 13 illustrates why certain information must, be communicated 
between SPEs. 

Figure 14 illustrates, in schematic form, a service pricing system. 

Figure 15 illustrates in schematic form the way in which a subscription 
service offers SDR information as a common resource to the post- 
processing systems. 

Figure 16 illustrates the billing chain within, and outside, a 
telecommunications operators organisation. 

Figure 17 illustrate the way in which consolidated billing permits a full range 
of services to be billed together on a single bill. 

Figure 18 illustrates the ways in which SDR information may be accessed 
in a variety of forms. 

Figure 19 „lus:rates the use of SDRs. and the information contained 
therem. for calculating the cost of service provision, signalling and 
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communication. 

A glossary of terms and a set of formal definitions is set out at the end of 
this specification to facilitate an understanding thereof. 

Turning now to Figures 1 to 4, an overview of a billing system, in 
accordance with the present invention, is given. 

The core functions of the flexible billing system of the present invention are: 
collection of data; 
debiting; 

invoice production; 
payment; 

payment verification; and 
follow-up. 

The billing chain of the present invention realises a process, comprising 
several stages. The present invention solves, inter alia, the problems associated 
with pricing and debiting. However, more is required of a billing system - SDRs 
must be collected, and invoices must be produced. 

Thus, it is necessary to: 

make sure that SDRs which can be priced, are collected, but no 
others; 

prepare the correct price list on the basis of the information in the 
SDR: 




WO 99/09733 PCT/SE98/01370 

- 19- 

price the SDRs as per the price list; 

make sure that the priced SDRs can be reached by MPS; and 

make sure that erroneous SDRs are fault-handled. 

The flexible billing system of the present invention incorporates a number 
of useful functions, e.g. pricing scheduler and SDR fault handler. This is 
illustrated in Figure 1. Within the overall service production module, there is 
located a register of service usage, a module for compiling pricing information and 
a module for creating SDRs. These units feed out data to the billing system, as 
shown in Figure 1. In addition, data may be fed out from the register of service 
usage to a module for defining price lists located in a service development 
element. Data from the module which compiles pricing information is fed to a 
module which identifies price lists, again located in the service development 
element. Data is also fed from the service development element to the billing 
system, as shown in Figure 1, which contains units for pricing service usage, 
analysing pricing information and collecting SDRs. 

The service and pricing scheduler are interlinked through the price list and 
SDRs. The price list defines what is to be priced and what it costs. The SDR 
refers to what can be priced in each individual case. 

Considering an individual pricing case, an SDR informs the pricing 
scheduler what can be priced for service usage. The price list gives the pricing 
scheduler the data it needs about the service so that it can correctly price an SDR. 

The system architecture used to implement the billing system is shown in 
Figure 2. The IN-service is supplied to a client, possibly via a data server 1. The 
client ,s linked, directly, or indirectly, with the billing system which conta.ns a pricing 
scheduler and pnce list systems, as shown. The billing system sends priced SDRs 
on to other sub-systems in the telecommunications system, such as the sub- 
systems labe.led MPS. FAKT and CAMS, via a data server 2. As shown in Figure 
2. three fundamental process are implemented by the system, namely: 



WO 99/09733 



PCT/SE98/01370 



-20- 

price list definition; 

price list identification; and 

production of priced SDRs. 

SDRs are moved from within a service production sub-system, i.e. a service 
producing element of the network, through the pricing scheduler in the billing 
system, to the invoicing train. The SDR has an information field which satisfies 
needs throughout the chain. 

Operation of the billing system is not affected by the way in which SDRs 
enter the database. Neither is it affected by where and how SDRs are created. 
The only requirement is that SDRs end up in the database. The client collects all 
SDRs to be priced. This is important, since there are SDRs which do not contain 
pricing information. The responsibility for the billing system starts with the client. 
The SDR comprises the interface between service and pricing scheduler. 

The pricing scheduler receives and analyses each individual SDR. The 
analysis results in a defined price list, if everything operates correctly. 

The price list system reads the SDR and picks out th« correct price, c 
prices. Some manipulation may be needed to come up with the correct p/ice for 
a given customer. 

When an SDR has been priced, it is sent to the MPS. It may be sent alone, 
or, together with other SDRs, in one file. The MPS only needs to collect the SDRs 
with FTP. It is necessary to store the SDRs until the MPS has collected them. 

The process of developing a service, as related to the billing system of the 
present invention, is illustrated in Figure 3. There are essentially three stages to 
this process: 

service development itself; 
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service production; and 



customisation. 



In the initial step of service development, it is necessary to develop the 
service functions, define price lists for the service, define SDRs and generate 
SORs. In the step of service production, product unique, and market unique, price 
lists must be produced. In the final stage of this process, customer unique price 
lists must be produced. 



A service will have a number of functions, which can be individually priced, 
using the billing system of the present invention. The precise charging regime is 
determined by the service. The billing system of the present invention does not 
impose any limitations on the charging possibilities. 

The price list defines what can be priced in the service. If something is to 
be to be priced, an SDR must also be generated. 

The SDR defines the basis for pricing. If an SDR is to be generated, the 
content must be defined. 
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In the stage of service production, the price list for the product if. defined 
with regard for the marketing company which is to sell the service. Each marketing 
company can have its own pricing and thus its own price list. However, it is only 
possible to price wnat is defined by the service. 

In the stage of customisation, the price list for the individual customer is 
defined. Unique customer agreements may entail unique price lists. Individual 
customer-service provider contracts may mean that a customer has his own pricing 
and thus his own c-ce list. 



25 



The pricing scheduler is a universal function within the billing system, i.e. 
it is completely transparent to the service. Everything that is service-un.que. 
customer-unique, c market-unique must be included in the price list. 
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New price lists can be entered during system operation. This covers both 
newly created services as well as supplemented existing services and modified 
pace bsts. The pricing scheduler must be able to find the correct price list despite 
changes during operation. 

A price list should be changed at predetermined times. The old price list 
can be written over. A price list must have a validity schedule. 

It is also possible to cancel price lists. 

For the pricing scheduler to be able to price an SDR, it must be identified 
It rs. therefore, necessary to search in the database where SDRs are stored and 
to mark any unpriced SDRs, as unpriced. 

In order to be able to price, the pricing scheduler must find the correct price 
list. An SDR contains information which identifies the correct price list. For 
example, an SDR may contain: 

the identity of the customer - this must always be included; 

the identity of the marketing company - this must always be 
included; 

the identity of the service to which it relates - this must be available 
for service usage pricing; 

access form - this must be available for access pricing; 
time - this must always be included; 
date - this must always be included; 



identity of the user; 
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connection; 
operator 
service provider; 



customer price - this indicates that a customer-unique price list is 
available; and 



market price - this indicates that a market-unique price list is 
available. 



All optional terms need not be specified to identify a price list. The correct 
pnce l,st is identified through all specified requirements being fulfilled. Otherwise 
no guarantee can be given that the correct price list will be identified. 

A general price list. i.e. one that is market-matched, or customised, is identified by 
the parameters: 



customer; 



marketing company; 



service; 



access form; 
time; and 



date 



Example: 



customer: 123456-7 
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marketing company: Telia Company 



service; Faxbox 



4. access form: Internet 



5. time: 14:33:15 



6. date: 30.11.96 



These parameters will give a general price list for a Telia service known 



Faxbox. 



as 



Example: 



10 



1 . customer: 1 23458-7 



2. marketing company: Telia Company 



service: 



Faxbox 



4. access form: Interne* 



5. time: 14:33:15 



6. date: 30.11.96 



15 



7. market price: YES 

These parameters will yield a market-unique price list for Faxbox. 

If the price list cannot be identified, the SDR is marked as being erroneous 
and the cause noted. 
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The pricing process is illustrated in Figure 4. The SDR contains tags for 
the number of services used during a session. 

The price lists may largely consist of a conventional list with prices running 
up and down, or it may have functions for analysis and calculation to enable the 
correct price to be arrived at. 

The price list system sets the price, and the pricing scheduler is thereby 
satisfied. In conjunction with pricing, the price list system marks the SDR as 
priced. 

For reasons of settlement with the Net and other networks, this form of 
access has its own tag and price list 

Priced SDRs must be marked as already priced. It may happen that an 
SDR cannot be priced. The SDR must be appropriately marked as follows: 

erroneous; 

fault cause; and/or 

fault detector. 

The SDR consists of a general part and a number of tags. The general 
part identifies the customer, and the tags report on services and access forms. 



Example: 
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Customer * 
identification 
Customer 
Marketing com- 
pany 
Time 
Date 

Weekday 



Access form A- 
ab 

PSTN 

A-No. 

Time 

Date 

Day 

Connect time 



Service 

Message Box 

Function: 

create 

Time 

Date 

Day 



Service 

Message Box 

Function: 

send 

Time 

Date 

Day 



Access form B- 
ab 

E-mail 

E-mail address 

Size 

Time 

Date 

Day 



An SDR must have space for information needed for 
identifying unpriced SDRs; 
identifying the correct price list; 
price marking; 

specifying the time of pricing; 

marking priced SDRs (signing i.e. the price list which has set the 
price); and 



marking erroneous SDRs 

An SDR. as previously explained, contains a substantial amount of 
information, which is needed to identify the correct price list SDRs are loaded with 
customer information and contain all the data needed. 

As previously explained, the traditional telephony network can be regarded 
as being divided ;nto an Information Services Network containing interacting 
Service Producing Elements and a Communication Services Network containing 
Service Switching Elements. The latter consist of a signalling network and a 
transport network The signalling network carries commands to the Service 
Switching Elemerts. for example, to establish a connection between two 
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geographical locations in the transport network. This network then conveys the 
information that is to be exchanged between these two locations such as voice 
text, picture, or data. 

Services created by this combination of information and communication are 
called infocom services. The Communication Services Network issues call detail 
records providing information about the geographical distance between the two 
locations being connected and for how long this connection has lasted This 
information is not sufficient for infocom service providers; hence, the Information 
Serv,ces Network issues service detail records (SDR). The purpose of the SDR 
■s to provide the information necessary to properly bill the usage and production 
of mfocom services. The SDR may also provide information to support service 
management quality assurance activities and production of statistics and reports 
about the service usage. 

A user. i.e. an individual, may take part in the generation of an SDR 
However, it is not necessarily essential for an individual to be directly involved in 
the generation of an SDR. An SDR may be created as a consequence of: 

a user making a phone call to a colleague; 

a facsimile message residing in a users fax box being retained for 
a further, period of time; 

3 - quality assurance activities prior to introducing a new infocom 

service; or 

a Service Producing Element reporting no call attempts have been 
made for the last 30 minutes 
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in the first two cases, a user interacts directly and indirectly with an infocom 
serv.ee. A service use session is produced and an SDR is issued to bill the user 
in the .atter two cases, the SDR is produced for quality assurance and service 
management purposes and not for billing. The present invention is primarily 
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concerned with the generation of SDRs as a resuit of a user interacting with an 
.nfocom service where the main purpose is billing the user for usage of the 
infocom service. 
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A Service Detail Record is a collection of tagged data items describing an 
•nfocom service use session. The basic structure of a tagged data item is 
■llustrated in Figure 5. The size and contents of the SDR may vary according to 
the mfocom services used and the way in which it has been used, it must be 
possible to append new data items to the SDR as, and when, new infocom 
services having different requirements emerge. To accomplish this, the SDR data 
structure must be flexible and expandab.e. hence the concept of using tagged 
data items. 



As shown in Figure 5. tagged data items have three basic components- a 
tag .dentifier. a length indicator and the actual data value. The tag identifier 
descnbes how the associated data value is to be interpreted. The length indicator 
g.ves the length of the data value, in terms of a number of octets, without the 
length of the tag identifier and the length indicator itself. For example, if the tag 
.dentifier says -price to pay' the associated data value will be interpreted as a sum 
of money. Because the data value may contain other tagged data items, nested 
structures are created, somewhat like a set of Chinese boxes. 

Tagged data items are positioned in sequence, one after another, with no 
spaces inserted between them and no spaces reserved for unused fields A 
tagged data item is recognized by the tag identifier value associated with it and 
may appear in any output from a Service Producing Element, hence additional 
tagged data items may be appended to it. e.g. by the Service Pricing System. 

Tagged data items are encoded according to the Basic Encoding Rules 
(BER, of the Abstract Syntax Notation Number One (ASN.1) as specified in the 
jo.n; iSO/CCITT se: of international standards/recommendations. An infocom 
sendee provider may take responsibility for assigning tag identifiers to the vanous 
data items in the SDR. 
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Related tagged data items are grouped into service modules. There are 
four different types of service modules within the SDR. The structure of a service 
module is illustrated in Figure 6. 

The Service Header Module contains data items associated with the SDR 
as a whole. There is always one such module in the SDR. 

The Network Service Module contains data items associated with the 
service's consumption of network capacity. There may be one. or several, network 
service modules in the SDR. Within the module, information about several 
network hops may be recorded. 

The Service Usage Module contains data items associated with the usage 
of an infocom service. The structure of a service usage module is shown in Figure 
7. There may be one, or several, such modules in the SDR. It contains data items 
that are present in all service usage modules and data items specific to a particular 



service. 



The Service Pricing Module contains data items associated with the pricing 
of an infocom service. There may be one. or several, such modules in the SDR. 

The structure of a service module is shown in more «<hm ; n Figure S. Esch 
serv.ee module has its own set of module specific tags. i.e. tags unique v^thiMhe 
context of that service module. The data items Service Module Identifier and 
Revision State are mandatory in all service modules. When these data items are 
combined with the module specific tags, the data items within that service module 
become globally unique, i.e. unique even outside the context of that service 
module. To make data items in a service usage module globally unique, a third 
data item, the Service Feature Code, is required. 

An ASN.Lencoder/decoder may be implemented as a state machine 
executing the 8ER and having access to look-up tables containing tag identifier 
values for different service modules. The decoding of an SDR begins with the 
state machine obtammg the Service Module Identifier and Revision State. Having 
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dcne this the proper look-up table for that sen/iro ^ , 
'n ft. SDR. ,„ ft. ^ of me sefvice U! 9 * 

7 s - - - ~ - — *** in L™ si: ^rrr 

.terns in the service usage module. Produced the data 

The relationship between service modules is illustrated in Figure 9 Th* 
SDR contains, when output from a Service Producing Element 1 

module ruui 'oouang sement, a service header 

module (SHM). one. or several, network service modules (NSM) and on. T 

several, sendee usage modules (SUM) When th. «w = 

Produced the price information theSDR TlT- P "* 9 h<K 

One *ZZ££T* " *** '° 3 SerV ' M 

Lr .r=Z.^r a = ~ 
o( designing an Infocom service. 

The -*■»-* ».0vean th. service modules within an SDR is governed 
by b» optona, data elaments. th. NSMrsu^om. b ,or and me SUWSPM 
Corre ator. No „ ^ „ ^ ^ ^ 

module of each type. If it contain savam, na^ . w rce — 5 - an Z, ™ 

onetontT ^ m0dU " S ~ is a 

one-to-one. or one-tcmany. relationship between these types of modules. 

Correlator. There . a one-to-one ralaBonship between these type, „ mKjules 
The sanes o, values o, th. ^ corral , yP . s musl bB unlque t Wn ~ 

The usage of an infocom service is called a service us, session. „ begins 
a a given date anc 3me . has a limifed dura ton and . venlua% ^ „ ^ 
date somanmea. and time, always. Ounng a service use session one oTa 
number. o, san,,ce events ta.a place. Several intocom services may compere a 
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either in sequence, or parallel, in time, to provide a more refined service. Hence, 
a service use session may contain events from several infocom services, see 
Figure 10. 

Events within the same infocom service are grouped into a service module. 
The chronological order in which the events take place are maintained in the SDR. 
A service use session may generate a single SDR - containing all service events 
within a single service, or within several cooperating services. It may also result 
in several related SDR's. each containing events within a single service, or an SDR 
for each service event, see Figure 1 1. For example, the Virtual Call Centre service 
produces one SDR containing all events, one. or several, in a service use session, 
whilst the Broad Band service generates one SDR for each event taking place. 

Whether, or not. a service use session results in one. or several. SDR's is 
irrelevant to the Service Pricing System which handles each SDR as an individual 
entity. The SDR contain two optional data elements, a Session Identifier and a 
Sequence Number to enable a post-processing system to recover the 
chronological order in which several related SDR's were produced during a service 
use session. Inside the SDR, events from an infocom service are grouped into a 
service usage module. Such a module is specific to an infocom service and may 
contain a single service event, or a chronological sequence of related service 
events, see Figure 12. 

The Service Pricing System appends the data items Basic Price and 
individual Price to the service pricing module. These data items may contain the 
price for an individual service event, or the total amount for all service events in the 
related service usage module. 

Service Producing Elements are part of the Information Services Network 
Customer data, for an individual customer, may be allocated to his home location 
SPE. Tne service logic of an infocom services may execute on a dedicated SPE. 
or be cistnbuted amongst several cooperating SPE's. 

If more than one Service Producing Element is participating in a service 
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use sess,on and. if more than one SDR is being output, they must coordinate the 
values of the data items Session Identifier and Sequence Number present in the 
SDR header, see Figure 13. which illustrates the need for certain information to 
be communicated between SPEs. 



Infocom services may be offered by several marketing companies with 
d.fferences in pricing, terms of payment, billing, etc.. Hence, it must be possible 
to pnce the provisioning and usage of infocom services according to price tables 
umque to each marketing company. It must a.so be possib.e to give the service 
providers and users individual rates, either in terms of absolute rates, or a basic 
rate, wrth varying discounts and bonuses applied later on. 

The service pricing system is illustrated in Figure 14. which shows the 
mteraction between the pricing scheduler, customer control data, service specific 
pnang .ogicand market/customer specific price tables in the production of priced 
SDRs. indicated by SSDR in Figure 14. from unpriced SDRs. 

Some services require rate, or price, information on demand, more or less 
m real time, in different languages and in different currencies before, during and 
.mmediateiy after the service has been used. It must be possible for the service 
provider to change the rates and prices of an infocom service instantaneously 
Th.s applies regardless of who is nroviding S0n „; C5 tr vAiZrri . ^ . . 

be a telecommunications network operator, or a customer . of the 
telecommunications network operator. 

The Service Pricing System handles the pricing of traffic rates and service 
events. Periodical charges, such as subscription charges, various discounts and 
bonuses must be calculated by the post-processing systems. 

A Service Producing Element delivers SDRs to a Subscription Service with 
an intermediate storage capability, the SDR-Archive. see Figure 15. Due to the 
gross amount of .rformation being produced, the SDRs are only retained in this 
archive for a lim,tec period of time. The postprocessing systems may subscribe 
to SDRs from several infocom services, or selected data items within SDRs from 
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a particular infocom service, for example, only those data items associated with 
billing. SDRs having no subscribers are discarded immediately upon reception by 
the Subscription Service. 



Those SDRs that do have subscribers are retained in the SDR-Archive for 
a specified period of time. The post-processing systems may ask the Subscription 
Serv.ce for information to which they, (post-processing systems), subscribe at 
recurrent time intervals, or may be alerted by the Subscription Service when they 
have information to collect. The SDRs are purged from the archive when all 
subscnbers have collected the information to which they subscribe. 

Some infocom services may issue an SDR as a request for price or rate 
•nformafion. Such an SDR is also sent to the Subscription Service and collected 
by the Service Pricing System. When the price, or rate, has been calculated and 
appended to the SDR it is returned to the Subscription Service and eventually 
fetched by the Service Producing Element that issued the request. 

The information in the SDR-Archive is a common resource available to the 
post-processing systems. The information is provided through the Subscription 
Service and may be used for different purposes. Some examp.es are set out 
below. 

a) Billing Inside and outside a telecommunications operator's organization 

The information in the SDR may be utilized to produce accounting 
information and enable a service producing company to verify invoices from 
domestic, as well as foreign, network providers. This information may be 
dtstnbuted amongst the venous infocom services ,o keep track on the amount of 
network capacity an infocom setvice has consumed. „ may be broken down 
further to show the n«work capacity a single service use session has consumed 
When mis is done it ,s possible to catculate the network cos, and associate i, to a 
specrfc network operator, an infocom service, or a service use session. Figure 16 
illustrates the dismbutton of revenues, in a billing chain, both inside, and outside 
a telecommunications organisation. 
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A service producing company may calculate the production cost to be 
printed on the invoice to marketing companies for providing them with infocom 
services. 

The production cost is the sum of the network cost and the service 
producing company's refinement cost and profit margin, which may vary from one 
marketing company to another. In the same way the service producing company 
may bill customers to the marketing companies simply by adding marketing 
expenses and profit margins to the service production cost. A customer may be 
either a user, or a provider, of infocom services. The service provider may be paid 
by cheque via the postal system, or by electronic money transfer. 

b) Consolidated billing 

Consolidated billing may reduce billing costs when multiple services are 
offered. It allows a full range of services to be billed together on a single bill. Bills 
cost money to produce in terms of hardware, software, paper and postage. Each 
bill will, hopefully, result in a payment which needs processing and it may generate 
customer enquiries - yet more cost. 

Opponents of consolidated billing argue that customers get a shock when 
they receive one large bill. But this may not be so. consider the-supcrmarket 
industry as an analogy: Gone are the days when people shop at the grocers, the 
bakers and the butchers in turn, spending a small amount in each. It is now 
accepted that a single trip to the supermarket, enables individuals to get 
everything required for a week and results in a single large bill. This has not 
inhibited the dominance of supermarkets. Customers are happy to pay the large 
supermarket bills for two key reasons: 

Convenience - a single place to shop, a single cheque to write; and 



Cost - supermarkets are perceived to be less expensive than 
smaller specialised stores. 
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Figure 17 illustrates the operation of a consolidated billing system and. in 
particular, the way in which consolidated billing permits a full range of services to 
be billed on a single bill. Infocom services may have their own dedicated billing 
systems subscribing to data elements containing information, such as price, 
currency and VAT. about that service. This speeds up the introduction of new 
services, or additions of new features, because only that particular serviced billing 
system needs to be modified. The rest of the service production environment 
stays intact. 



I5 



When the total amount for the stipulated period has been calculated on a 
10 per customer basis, account service information is transferred to the invoice 

printing machine common to all services. This machine applies volume discounts 
and bonuses comprising the full range of services a customer subscribes to and 
prints a single bill/invoice. 

c) Reports and statistics 

The information present in the SDR is a valuable asset to a 
telecommunications operator. Figure 18 shows the way in which information 
contained in SDRs may be used for the production and delivery of management 
reports and statistics. It may be used to gain knowledge of how the service 
production environment is functioning, hoy !h? infocom services are useJ. wiiai 
revenues they generate and customer behaviour. It may. of course., also be 
offered to customers in the form of reports. 

The information in SDRs may be used to produce service specific revenue 
reports, sales reports, marketing reports and customer behaviour reports to the 
sen/ice provider, the marketing companies and their customers. The product 
manager can switch on his. or her. personal computer on arrival at the office in the 
morning and get fresh information about the revenues his. or her. product has 
generated up to the previous day. This information may be analysed and trigger 
development of new services, service features, or refinement of existing services. 
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tomers. marketing companies and all others taking part in the service 
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production, can order SDR-derived information in a number of different ways and 
forms. Ordering may be carried out by electronic mail, facsimile, phone. Internet, 
or snail mail, either as a one time delivery, or as a subscription. The information 
content may be tailored in a variety of ways to suit a particular customer's needs. 
5 e.g. by type of information, the infocom service to which it relates, customer, 

company, and/or the time interval in which it was, or will be, produced. 

Delivery may be carried out by e-mail, facsimile, phone, Internet, electronic 
data interchange (EDI), or snail mail, containing CD-ROM, or paper. The 
information delivered may be in a final state, or prepared for further refinement by 
! 0 the customer. In the latter case, the information may be contained in a Microsoft 

Word document, an Excel spread sheet, or Power Point pictures, that may be 
printed out on transparencies. 

a; Quality assurance 
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SDRs may be generated for quality assurance purposes. For example, 
prior to marketing a new service feature it is important to verify that it has been 
correctly priced and that the invoice looks an right. However, it is equally important 
not to put this invoice in an envelope and mail it. 

e) Service management 

SDR's may be generated for service management purposes, for example, 
") to obtain an early indication of suspected fraud attempts, churning, abnormal 

traffic loads, failure rates, or technical errors. 

To determine the cost for producing a sen/ice use session, information 
about consumed communications network capacity must be obtained. This 
includes all network providers who have put their signalling and transport networks 
25 at the services disposal. Figure 19 shows how an SDR may contain information 

from a variety of sources, all of which is needed to calculate the cost of service 
provision, signalling and communication. 
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ln the example illustrated in Figure 19. a Swedish company, with sites in 
Europe, subscribes to a virtual private network service - VPN. The sites share a 
common private numbering plan (PNP) and the service logic executes on a 
Service Producing Element in Sweden. The signalling and exchange of 
information takes place within domestic and foreign network providers' networks 
via Signal Switching Elements (SSE). 

When A calls B at the site in Spain, it is signalled to the SPE in Sweden. 
The service finds out that A and B are connected to the same VPN and 
establishes a voice-channel between A and B in the Spanish operators network. 
When A hangs up. an SDR is produced at the SPE in Sweden giving details of 
consumed signalling capacity between Spain and Sweden, via France and 
Germany, and the communication capacity used in the Spanish operators network. 

The invoices from the network providers may cover the total amount of 
network capacity consumed by various infocom services. The SDR must provide 
sufficient information to enable the service provider to calculate the amount of 
capacity a specific infocom service has consumed. 

The structure of SDRs and data items included therein will now be 
described. It will be noted that some data items are mandatory while others are 
optional. SDRs, as has already been exDlained am generated »s a consequence 
of a user interacting with an infocom service. The main purpose of the SDR is to 
bill the user for the usage. SDRs generated as a consequence of service 
management, quality assurance activities, or other activities are not described 
Herein. 

Data items in the Service Header Module are appended by the Service 
Production Elements. All data items, mandatory, or optional, appear only once 
within the module. The following data items belong to this module. 

Service Module Identifier - Identifies the service header module. 
[MANDATORY]. 
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Revision State - The version of the ASN.1 data type defining the service 
header module. A module in a given version must not be altered 
[MANDATORY]. 

SDR Type - Identifies the type of SDR. The specific values are: 
5 - Billing; 

Quality Assurance; 
Service Management; 
Statistics; 

Accounting, within telecommunications . operator's own 
10 organisation; and 

Accounting, other telecommunications operator. 

If a service has a qualifying period and the user hangs up, upon receiving 
the rate information, the user will not be billed but an SDR for accounting 
may be issued so thatih« notwnH, provider gets pairt. [MANDATORY] 

Session Identifier - May be used to identify several SDRs associated with 
a session. If SDRs within a session are produced by different Service 
Producing Elements, the Session Identifier must be communicated 
between the Service Producing Elements so it has the same value in all 
SDRs. [OPTIONAL] 

Sequence Number - May be used to indicate the sequence, within a 
session, in which several related SDRs have been produced. The 
Sequence Number may be useful when a service use session results in 
several SDRs being output, or if a service use session extends over a long 
time period, as is the case with leased lines. If SDRs. within a session, are 
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produced by different Service Producing Elements, the Sequence Number 
must be communicated between the Service Producing Elements so it 
forms an unbroken sequence. [OPTIONAL] 

SDR Identifier - Uniquely identifies an SDR that has been produced by a 
5 particular Service Producing Element. This identifier may be used to 

distinguish between duplicates. The SDR Identifier may be represented as 
a 32 bit integer, incremented once for each SDR being produced. This 
gives a sequence of 4,294,967,295 unique identifiers before the sequence 
is repeated. (MANDATORY] 

Date Of Origin - Specifies the date on which the SDR was produced. 
[MANDATORY] 

Time Of Origin - Specifies the time of day when the SDR was produced. 
[MANDATORY] 

Responsibility Trace - May be used by a system taking part in service 
15 production to indicate that it has taken responsibility for the SDR, hence it 

may contain a sequence of system identifiers and time stamps. The 
Responsibility Trace may be used as follows:- when a Sen/ice Producing 
Element delivers the SDR to the Service D ncing System and the latter i-,a:> 
secured it. the Service Pricing System may indicate this by appending a 
20 responsibility tag and the Service Producing Element may purge the SDR 

from its storage. [MANDATORY] 

Action Indicator - Indicates what kind of action the Service Pricing System 
is requested to perform. The specific values are: 

the SZR shall be priced and forwarded to a post-processing 
-5 system 



the S3R is a request for price, or rate, information and shall be 
returned to the Service Producing Element; 
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the SDR is for quality assurance and shall not be priced; 

the SDR is for service management and shall not be priced 
[MANDATORY] 

Data items in the Network Service Module are appended by the Services 
Producing Element. Data items, mandatory, or optional, may appear more than 
once within the module, as indicated. The following data items belong to this 
module. 

Service Module Identifier - Identifies the network service module. 
[MANDATORY] 

Revision State - The version of the ASN.1 data type defining the network 
service module. A module in a given version must not be altered. 
[MANDATORY] 

NSM/SUM Correlator - If the SDR contains more than one network service 
module, each module must have an identifier value that is unique within 
the SDR. This same value shall be present in all, one, or many, service 
usage modules associated with this network service module. [OPTIONAL] 

The following set of data items may appear several times w|thin the 
module. If they do. the whole set is repeated as an unbroken sequence. 

Network Provider - Identifies the network provider having put his network 
20 to the services disposal. [MANDATORY] 

Type Of Network - The type of network having been used, for example, a 
signalling network. IP-network, or a voice channel. [MANDATORY] 

Date For Start Of Charging - Specifies the date on which the charging 
duration stars. [MANDATORY] 
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Time For Start Of Charging - Specifies the time of day at which the 
charging duration starts. [MANDATORY] 

Chargeable Duration - Specifies the time period for which a charge has to 
be calculated. [MANDATORY] 



SSE Identifier - Uniquely identifies the service switching element 
[OPTIONAL] 

The following data items may be present in the static part of the TT- 
information produced by a telecommunications operator's VPN-service. 



Record Size - 

Cause For Output - 

Record Number • 

Call Id Number - 

Record Sequence Number - 

Fault Code - 

Call Status - 

Forced Disconnection - 
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Consumed Capacity - [OPTIONAL] 
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Record Type - 



Call Attempt Indicator- 



WO 99/09733 



PCT/SE98/01370 



-42- 



Call Attempt State - 
Cause Code - 
Location Code - 
Type Of Signalling - 
Type Of A-subscriber - 

Length Indicator A-subscriber - not present in TT-info from MSE 

A-subscriber Number - 

A-category - 

Type Of A-number- 

A-subscriber Numbering Plan - 

Type Of B-subscriber - 

Length Indicator B-subscriber - not present in TT-info from MSE , 

B-subscriber Number • 

B-category (EOS information) 

Type Of B-number- 

B-subscriber Numbering Plan - 

Charging Case - 
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Charged Party - 
Origin For Charging - 
Telecommunication Service Code - 
Type Of Seizure - 
Type Of Indicator - 
Type Of Procedure - 

Result Of Subscriber Service Procedure - 

Date For Start Of Charging - 

Time For Start Charging 24h - 

Chargeable Duration/Time - 

Time From Reg. Seizure To Start Of Charging - 

Number Of Meter Pulses - 

Number Of User-To-User Messages In Call Control Messages - 
Number Of User-To-User Messages During Call - 
End To End Access Data Indicator - 
End To End Access Data Map - 
End To End Access Data Counter - 



# 
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Length Indicator X-subscriber - not present in TT-info from MSE 

X-subscriber Number - not present in TT-info from MSE 

Length Indicator Abbreviated Number - not present in TT-info from MSE 

Abbreviated Number - 

Conference Call Indicator - 

Presentation Indicator (CUR) - 

Originating Code - 

Destination Code - 

Exchange Identity - 

Outgoing Route - 

Incoming Route - 

Cam'er Access Code - 

Date Of Command - not present in TT-info from MSE 
Time Of Command - not present in TT-info from MSE 
Command Name - not present in TT- info from MSE 
following data items may be gathered from a CDR Message. 
CDR Message Type - 
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CDR Record Size - 

Exchange Identifier AX.Id - 

File Identifier - 

(Sub)File Number - 

Record Sequence Number 

Record Type - 

Call Identification Number - 

Call Status * 

Cause For Output - 

Partial Record Number - 
A-Number - 
A-Category - 
A- Number Type - 
A-Number Plan Indicator - 
A-Subscriber Type - 
8-Number - 
B-Number Type - 
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B-Number Plan Indicator - 
C-Number - 

Dialled Digits To IN Service - 
Record Sequence Number IS/TT - 
VPN Call Information - 
Oate For Start Of Charging - 
Time For Start Of Charging - 
Chargeable Duration - 
Interruption Time - 
Fault Code (EOS) - 
Abbreviated Number - 
Origin Of Charging - 
Type Of Seizure TOS - 

Telecommunication Service Indicator Code TSC - 

Call Indicator CI - 

Result Of Procedure - 

Subscriber Service Indicator SSI/TOI - 
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Subscriber Service Indicator SSP/TOP - 
Conference Call Indicator - 
Midnight Line Service - 
Network Conversion Facility - 

User-To-User Messages During Call Control (UUS1) - 

User-To-User Messages During The Call (UUS2 - 3) - 

ISDN Subscriber Service Indicator 1 - 

ISDN Subscriber Service Procedure 1 - 

ISDN Subscriber Service Indicator 2 - 

ISDN Subscriber Service Procedure 2- 

iSDN Subscriber Service Indicator 3 - 

ISDN Subscriber Service Procedure 3 - 

ISDN Subscriber Service Indicator 4 - 

ISDN Subscriber Service Procedure 4- 

Special Information (Miscellaneous) - 

Customer project - 

TIMS Price - 
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Credit Card Number - 

General Account Number - 

Charged Participant - 

Service identifier - 

Type Of Access - 

VPN Call Type- 

IN Call Indicator - 

Function Trace x 4- 

IS-TT Duplicating Sequence Number - 
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MRS Status - 



Price 1 - 



Price 2 



Price 3 - 



Price 4 - 
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Call Type 1 For Price 1 - 



Call Type 2 For Price 2 - 



Rate Period Identifier 1 - 
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Multiple Rate Periods 1 - 

Multiple Rate Periods 2- 

Price Table Identifier - 

VAT Identifier 1 - 

VAT Identifier 2 - 

Bill Service Identifier - 

Purpose For Billing - 

Rating Status - 

Repair Status - 

Service Type Indicator * 

Charged Subscriber Number - 

Charged Subscriber Number Plan Indicator - 

Call Session Indicator - 

A service usage module is specific to an infocom service in the sense that 
it contains data itens present in all service usage modules and data items related 
to a particular infcccm service. 

Data items present in all service usage modules are appended by the 
Services Producing Element. All data items, mandatory, or optional, appear only 
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once in the module. The following data items belong to the Service Usage 
Module. 

Service Module Identifier - Identifies the service usage module 
[MANDATORY] 

Revision State -The version of the ASN.1 data type common to all service 
usage modules. A module In a given version must not be altered 
(MANDATORY] 

Service Feature Code - Identifies this particular infocom service 
[MANDATORY] 

Revision State Of Service - The version of the ASN.1 data type specific to 
this service module. A service module in a given version must not be 
altered. [MANDATORY] 

User Identifier - Identifies the infocom service user. The user may be 
identical to the provider, as is the case when a service provider changes 
the rates, or updates information. If an SDR contains both a User Identifier 
and a Calling Number, or A-subscriber Number, the User Identifier 
overrides them all. [OPTIONALI 

Provider Identifier - Identifies the infocom service provider. [MANDATORY] 

Marketing Company - Identifies the marketing company that the customer 
20 belongs to. The specific values, for Telia, are: 

- Telia MegaCom; 

- Telia PubliCom; 
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- Telia Nara; 

- Telia A/S (Denmark); 

- Telia Norge AS 

- Telia Polen; 

5 - Telia Estland; 

- Telivo Oy (Finland): 

- Netia (Poland); 

- North West GSM (St Petersburg); 

- Estonian telephone Company; 
0 - Latvian Mobile Telephone; 

- Teiemedia AB (Lithuania). [MANDATORY] 

Charged Participant - May be used to indicate that someone other than the 
User. Calling Number, or A-Subscriber Number, is to be charged. One 
example is an ordinary collect call. [OPTIONAL] 

5 Dialled Number - The dialled number used for the call connection, i.e. 

dialled digits to the infocom service. [MANDATORY] 

NSM/SUM Correlator - If the SDR contains more than one network service 
module, each such module must have an identifier value that is unique 
within the SDR. This same value shall be present in this (and all other) 
0 service usage modules associated with the network service module. 

[OPTIONAL] 
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SUM/SPM Correlator - If the SDR contains more than one service usage 
module, each such module must have an identifier value that is unique 
within the SDR. This same value shall be present in the network service 
module associated with this service usage module. [OPTIONAL] 

Data items specific to the Virtual Call Centre Service Usage Module are 
appended by the Services Producing Element. Data items, mandatory or 
opbonal. may appear several times within the module, as indicated. The following 
data items belong to this module. 

Calling Number - The phone number of the calling party. [MANDATORY, 

Dialled Number. The Call Centre access number, i.e. the number dialled 
by the calling party to reach the service. [MANDATORY] 

Service Carrier - The service, or call type, that carries the call to the Call 
Centre. The specific values, for Telia, are: 

- Telia Frisamtal; 

- Telia Freephone; 

- Telia Foretagsnummer; 

- Telia Foretagsabonnemang; 

- Telia Split (1. 2. 3). [MANDATORY] 

Customer Control Code - values for this data item may be defined in a 
future version of the VCC service. 

Having reached a destination number, the calling party may once again be 
put ,n queue. If so. the following data items shall be repeated as an unbroken 
sequence and in chronological order within the module. Each sequence of data 
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Destination Number - The phone number of the answering party. 
(MANDATORY] 

Event Code - The specific values are: 

- The calling party was put in queue and hung up; 

- The calling party was put in queue and reached a destination number; 

- The calling party immediately reached a destination number. 
[MANDATORY] 

Date For Start Of Charging-1 - Specifies the date on which the calling party 
was put in a queue. [OPTIONAL] 

Time For Start Of Charging-1 - Specifies the time of day at which the 
calling party was put in a queue. [OPTIONAL) 

Chargeable Duration-1 - Specifies the time period the calling party has 
spent queuing. [OPTIONAL] 

Date For Start Of Charging-2 - Specifies the date on which the calling party 
reached a destination number. [OPTIONAL] 

Time For S:art Of Charging-2 - Specifies the time of day at which the 
calling party reached a destination number. [OPTIONAL] 

Chargeable Duration-2 - Specifies the time period the calling party has 
been connected to the destination number. [OPTIONAL] 

Data items specific to the Virtual Private Network Service Usage Module 
appended by fce Services Producing Element. Data items, mandatory, or 
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optional, may appear several times within the module, as indicated. The following 
data items belong to this module. 



Private Number A-subscriber - If the A-subscriber has a private number, 
this number is stored. {OPTIONAL] 

Public Number A-subscriber - If the A-subscriber has a public number, this 
number is stored. [OPTIONAL] 

Private Number B-subscriber- If the private number of the B-subscriber is 
used to set up the call, this number is stored. [OPTIONAL] 

Public Number B-subscriber - If the public number of the B-subscriber is 
used to set up the call, this number is stored. [OPTIONAL) 

First Destination Number - If a routing or diversion feature is used, the 
destination number is written here. [OPTIONAL] 

Second Destination Number - If the Call Forwarding feature is used on a 
destination number that was already output from a Call Forwarding feature, 
this destination number is written here. [OPTIONAL) 

Third Destination Number - If the Call Forwarding feature is used on a 
destination number that was already output from a Call Forwarding feature, 
this destination number is written here. [OPTIONAL] 

Cost Distribution Code (CDC) - The CDC assigned to the A-subscriber. or 
his PABX. is written here. In case of GVNS and Call Centre Access, the 
value of this data item is filled with zeroes. [OPTIONAL] 

Extra CDC 1 - The CDC assigned to the subscriber, or the PABX, of "First 
Destination Number is written here. [OPTIONAL] 



Extra CDC 2 - The CDC assigned to the user, or the PABX. of "Second 
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Destination Number" is written here. [OPTIONAL] 



Extra CDC 3- The CDC assigned to the user, or the PABX, of "Third 
Destination Number" is written here. [OPTIONAL] 



Account Number - [OPTIONAL] 



Type Of Access - The specific values are: 



- Direct; 

- GVNS; 

- Switched; 

- Remote; 

10 - Call Centre: 



- Network Remote. [MANDATORY] 



Originating Line Identity (OLID) - The OLID that is added in case of Direct 
Access. [OPTIONAL] 

Terminating Line Identity (TUD) - The TLID that is added in case of direct 
termination, or 8reak-out. [OPTIONAL] 

Dialled Number - The dialled number used for the call connection, i.e. 
dialled digits to the VPN service. (MANDATORY] 

Call Type - The specific values are: 



Call terminated to On-net; 
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- Call terminated to Off-net: 

- Call terminated to Virtual On-net. (OPTIONAL] 

Follow On Counter - Starts counting from the first follow-on call in a 
Remote Access, or Network Remote Access call. i.e. from the second 
destination number to which the caller is connected. In case of follow-on 
calls, an SDR is generated for every call. The SDR includes ID and 
Related ID. The first SDR has no Related ID. The next SDRs have the ID 
of the first as Related ID. [OPTIONAL] 

Event Trace - Each time an event is executed in call handling, the specific 
value for that event is added. An event that is executed several times will 
appear several times with its value. The specific values are: 

- Forced On-net; 

- Privilege Override; 

- Direct Termination Overflow; 

- Break -Out; 



- Call Diversion on Busy; 

- Call Diversion on No Replay; 

- Time-Dependent Routing; 

- Call Screening (that is initial Number list); 

- Follow-Me: 



- Origin-Dependent Routing: 
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- Call Distribution; 

- Leased Virtual Channels - no overflow; 

- Leased Virtual Channels - overflow; 

• Customer Control - PIN; 

• Customer Control - Time-Dependent Routing; 

- Customer Control - Advanced Forced On-net; 

- Customer Control - Follow-Me, activate, own phone; 

- Customer Control - Follow-Me, activate, other phone; 

• Customer Control - Follow-Me, deactivate, own phone; 

- Customer Control - Follow-Me t deactivate, other phone; 

• Customer Control - Language Code; 

- Overflow; 

- Differentiated Call Screening. [OPTIONAL] 

These event values shall be presented in chronological order with the 
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latest event first 



Type of Redirection Indicator - The specific values are: 



- General failure; 



- General congestion; 
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- Congestion inside the VPN, 

• Congestion outside the VPN; 

- Failure inside the VPN; 

- Failure outside the VPN. [OPTIONAL] 

5 In case Direct Termination Overflow has been used, this data item shows 

whether redirection was done due to congestion, or due to failure. 

Authorisation Code - In case of remote access and network remote access 
the user identifies himself by entering his authorisation code and P.N This 
data item contains only the authorisation code and not the P.N 
10 [OPTIONAL] 

Company Identifier - An identifier assigned to the subscribing company 
Th,s ,s the Company Identifier of the calling party, except in the case of 
GVNS and Call Centre Access, when it is the Company Identifier of the 
called party. [OPTIONAL] 
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Authorisation Code Version 2 - (OPTIONAL] 
IN Call Indicator - [OPTIONAL) 

Non Dialabie Private CLI - (calling line identity) [OPTIONAL] 
Non Dialat:e Public CLI - [OPTIONAL] 
Personal P*one Number - [OPTIONAL] 

When mafcrg .-emote access calls, or network remote access calls in the 
Teha VPN service, ,e data item Authorisation Code contains the A-number to be 
charged. .... the hc-re number of the calling party. (The calling party enters his 
pubbc Phone nurrcer as authorisation code.) The data item Public Number A- 
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subscriber contains the A-number to be used for price calculation, i.e. the number 
of the phone outside the VPN that has been used to make the remote access call. 

Data items specific to the Signalled Asynchronous Transfer Mode Service 
Usage Module are appended by the Services Producing Element. Data items, 
mandatory, or optional, may appear several times within the module, as indicated. 
The following data items belong to this module. 



Originating Number - (format E164 string). [MANDATORY) 

Terminating Number - (format: E164 string). [MANDATORY] 

Date For Start Of Charging - Specifies the date on which the charging 
10 duration starts. [MANDATORY] 



Time For Start Of Charging - Specifies the time of day at which the 
charging duration starts. [MANDATORY] 

Chargeable Duration - Specifies the time period for which charge has to be 
calculated. [MANDATORY] 

Peak Allocate* Bandwidth [MANDATORY] 



Average Allocated Bandwidth - [MANDATORY] 

Class Of Service - (MANDATORY] 

Number Of Transmitted Cells/Frames - [MANDATORY] 



Data items specific to the Broad Band Service Usage Module are 
appended by the Services Producing Element. Data items, mandatory, or 
optional, may appear several times within the module, as indicated. The following 
data items belong to this module. 
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ATM Service tdentifier - Identifies a service within the ATM service 
[MANDATORY] 

Date For Start Of Charging - Specifies the date on which the charging 
duration starts. [MANDATORY] 

Time For Start Of Charging - Specifies the time of day at which the 
charging duration starts. [MANDATORY] 

Chargeable Duration - Specifies the time period for which charge has to be 
calculated. [MANDATORY] 

Session Identifier - May be used by the Service Pricing System and a post- 
processing system to recognize several events taking place during a 
session. [MANDATORY] 

Type Of Event - Identifies the type having caused the output of this SDR. 
e.g. tog in. log off, or change of home page on the web. [MANDATORY] 

Event Parameters - A set of parameters associated with the event, e.g. 
http protocol, video conference, address of home page, type of 
information, or TCP'IP-addresses. [MANDATORY] 



This service issues an SDR every time a service event has taken place. 
Hence, the Session Identifier may be used to associate events to a particular 
session. This is contrary to the VCC service where associated events are output 
20 in the same SDR. 

Data items in the Service Pricing Module are appended by the Services 
Pricing System. Data items, mandatory, or optional, may appear several times 
within the module, as indicated. The following data items belong to this module 
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Service Module Identifier - 
[MANDATORY] 



Identifies the service pricing module 
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Revision State - The version of the ASN.1 data type defining the service 
pricing module. A module in a given version must not be altered. 
(MANDATORY] 

SUM/SPM Correlator • If the SDR contains more than one service usage 
module, each such module must have an identifier value that is unique 
within the SDR. This same value shall be present in the network service 
module associated with the service usage module. (OPTIONAL! 

Service Pricing Identifier - Identifies the Service Pricing System which 
calculated the price for the associated service usage module, or provided 
the requested price, or rate information. [OPTIONAL] 

Date Of Pricing - The date the price information was calculated. 
(MANDATORY] 

Time Of Pricing - The time of day the price information was calculated. 
(MANDATORY] 

Currency - The currency that has been applied to calculate the price 
information. (MANDATORY] 

Value Added Tax - The level of VAT that shall be applied to the data items 
Basic Price and Individual Price. [MANDATORY] 

A service usage module may contain several events. The price for each 
20 evem ma y either De added up to a total amount, or presented as individual 

amounts. If the tatter is the case, the following data items shall be repeated as an 
unbroken sequence within the module. The order within that sequence shall 
correspond to the sequence of events in the associated service usage module, as 
indicated by the SUM/SPM Correlator. 



IS 
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Price Type - Indicates if the Price Information has been calculated on a pei 
call basis, per function, per time-slice, or a combination of these 
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(MANDATORY] 

spec** cutrency. exclusive 0/ VAT end any discounts. (MANDATORY] 

M*M Pnce -The besic pnce in the specified currency with applied 
discount,, but exdusiveo, VAT. This is the price the user snal, pav A 
d»coun, may be 8ranted „ „. usef has ,„ ^ 

w* the mantebng company, or because the service was used during a low 
rate period. (OPTIONAL] 

Pdce Table IdenWea the price table used to calculate ,h. Pnce 

Information. [MANDATORY] 

Revision State - The version of the price table used to calculate the Pnce 
information. A price table in a given version must not be altered 
[MANDATORY] ° 

Bifl information - Indicates to a post-processing system what to print on the 
bill. What is actually printed may depend on the service, the provider and 
the user. [OPTIONAL] 

Status Indicator- Indicates if the SDR has been priced, or the reason why 
it cannot be priced. The specific values are: 



- The price has been properly calculated; 

- Unable to locate the Service Feature Code; 

- Unable to locate the Revision State Of Feature; 

- Unable to locate the service user; 



Unable to locate the marketing company; 
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- Unable to locate the price table: 

- Unable to price due to technical error. [MANDATORY] 

To assist with understanding the present invention, a glossary of the terms 
used in this patent specification is set out below. 

ASN.1: Abstract Syntax Notation One - is a syntax specifying how data 
types and their associated values shall be represented. Any other 
modem common programming language may serve the same 
purpose, e.g. Ada, or C. ASN.1 was developed in the early eighties 
and is nowadays defined in the CCITT recommendation X.208 and 
the ISO-standard 8824 as belonging to the presentation layer of the 
OSl-model. 

ATM: Asynchronous Transfer Mode 

Ax: Automatic Exchange 

BER: Basic Encoding Rules are a set of rules specifying how the ASN. 1 

data types and their associated values shall be encoded to a 
transfer syntax, i.e. a seouppro 0 f octetr The binary 
representation of these sequences of octets is called transfer code 
and is independent of the programming language and operational 
system being used. The transfer code is used when the data types 
and their associated values are being exchanged between open 
systems, i.e. systems conforming to the OSl-model. BER is 
defined in the CCITT-recommendation X.209 and the ISO-standard 
8825. 

CAMS: Customer Account Management System - in the present invention 

CAMS produces invoices for transmission to customers. CAMS 
creates periodic invoices for monthly, or quarterly delivery, periodic 
charges may be priced in CAMS which can also produce one-time 
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invoices and credit notes. 



CDR: 



CSN: 



Call Detail Record is a data structure describing how a connectivity 
network has been used. e.g. in terms of connection time and the 
geographical distance between the points of connection This 
information however, is not sufficient to bill infocom services 



Connectivity Services Network - The CSN 
services: 



provides three kinds of 
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FAKT: 

FTP: 
IN: 

Infocom: 
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ISN: 



a signalling service, e.g. to connect users of infocom 
services; 

a transport service to convey voice, text, picture and data 
between users of infocom services; and 

an announcements/play messages service, this service may 
include other forms of outputs from intelligent peripherals. 

a known and existing invoice system used in the billing chain for 
creating basic invoice data on priced posts. 

FiJe Transfer Protocol 

Intelligent Network 

Infocom services are produced in the Information Services Network 
consisting mainly of service data points (SDP). service control 
po.nts (SCP) and intelligent peripherals (IP). , n this context the 
connectivity network provides the infra structure to the services. 

Information Services Network - makes use of the Connectivity 
Services Network to provide infocom services. 
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MPS: When a customers makes a telephone call over the fixed network. 

one. or several, callposts, e.g. TT-posts are created. Files with TT- 
posts are gathered together by an IS-TT system. The callposts are 
then sent to MPS for validation. 



NSM: Networit Service Module 

PNP: Private Numbering Plan 

SCP: Service Control Point 

SDP: Service Data Point 



SDR: 
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Service Detail Record - SDR is a data structure describing how an 
infocom service has been used. Such a use case may involve only 
one service, or a sequence of cooperating services. ASN.1 and 
BER are applied to specify and encode/decode this data structure. 

SDR-Archive: Information in the SDR is stored in a relational data base called the 
SDR-Archive. The information may be retrieved by post-processing 
systems, e.g. to produce bills, statistics and reports. The 
information resides for different psricds off time on different types 
of storage media with varying capacity and access times. Pricing 
information may be present in the SDR when it enters the SDR- 
Archive. or applied later on. by the post-processing Systems. 

20 SHM: Service Header Module 

SPE: service Producing Element - A SPE is part of the Information 

Servces Network. The SPE may issue an SDR each time a 
service event takes place, or wait until a service use session has 
been completed. The behaviour depends on the particular infocom 
25 service. 
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SPM: Service Pricing Module 



SPS: 



10 



TC 

15 



Serv.ce Pricing System. The SPS provides rating and pricing 
^formation, on demand and in real-time, to infocom services it 
also performs pricing of SDR's when output from the Service 
Producing Element The Service Pricing System contains price and 
rate tables for various infocom services, marketing companies and 
customers. It also has the logic necessary to calculate the correct 
pr.ce for a service use session consisting of one, or many co- 
operating services, provided by any marketing co mpany t0 any 
customer; this includes applying the appropriate currency VAT 
together with various discounts and bonuses. 



SSE: Service Switching Element 

SUM: Service Usage Module 



Transfer Code is the binary value of the octet string produced when 
BER is applied to an ASN.1 data type. Transfer syntax is another 
name for transfer code. 



20 



TT record: Toll Ticketing record 
VCC: Virtual Call Centre 

VPN: Virtual Private Network 

Within the context of the present invention, as herein described the 
following list of def -:ions apply. 

Bill: To ask and cc set payment for the usage of an infocom service. 

Charge: The cha-; e established and collected by a service provider from its 
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customers for the use of an infocom service. 

Customer A customer may be the user and/or the provider of an infocom sen/ice. 

Price: An amount of money independent of time. The price is calculated as the 
product of a given rate and the chargeable time duration. 

Rate: An amount of money as a function of time. 

SDR: An ASN.1 data type describing a specific service use session. 

Service Event: An event taking place within a specific infocom sen/ice. 



Service Usage: A service use session triggered by a human being, or an infocom 



Service Usage Module: An ASN.1 data type describing one, or several, service 



Service use session: May consist of one, or several, service events taking place 
within a single infocom service, or several interacting infocom services. 

Tariff: A list of prices or rates. 



service. 



events. 
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CLAIMS 

1 • A telecommunications billing system, for use with a telecommun.cations 
system comprising: 

an information services network containing a plurality of service 
producing elements; and 

a communication services network containing: 

a plurality of service switching elements; 

a signalling network; and 

a transport network; 

said telecommunications system being adapted to provide infocom services to 
customers and said billing system being adapted to provide flexible pricing and 
billing for usage of infocom services, characterised in that said billing system 
includes handler means for receiving SORs generated by said service producing 
elements and transmitting said SDRs to p s^ice pncing scheduler r.wans. in ti .« 
said SDRs include Service Usage Modules, in that said service pricing scheduler 
means is adapted to associate a Service Usage Module with a price list 
appropriate thereto, and in that pricing means are provided for calculatmg a price 
associated with a Service Usage Module and inserting said price in a Service 
Pricing Module associated with said Service Usage Module. 

2. A telecommunications billing system, as claimed in claim 1 . characterised 
in that, after insertion of a price in a Service Pricing Module, said pricing scheduler 
means is adapted to return a priced SDR to said handler means. 

3. A telecommunications billing system, as claimed in claim 2. characterised 
in that said handler means is adapted to transmit priced SDRs to a SDR arch.ve 
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means adapted to store said priced SORs until they are transmitted to a post- 
processing system. 

4. A telecommunications billing system, as claimed in any previous claim, 
characterised in that a sen/ice use session generates one. or more SDRs. 

5. A telecommunications billing system, as claimed in any previous claim, 
characterised in that Service Pricing Modules are added to SDRs. only after an 
SDR has been priced. 

6. A telecommunications billing system, as claimed in any previous claim, 
characterised in that each SDR is a collection of tagged data items describing a 
service use session. 

7. A telecommunications billing system, as claimed in claim 6, characterised 
in that an SDR's size and content varies in accordance with an infocom service to 
which it relates. 

8. A telecommunications billing system, as claimed in either claim 6. or 7, 
characterised in that tagged data items in an SDR are encoded using the BER for 
ASN.1. 

9. A telecommunications billing system, as claimed in any of claims 6 to 8. 
characterised in that related tagged data items in an SDR are grouped into service 
modules. 

10. A telecommunications billing system, as claimed in claim 9. characterised 
. in that a particular set of related tagged data items in an SDR are grouped into one 

of the following four types of service module: 

a Sen/ice Header Module, which contains tagged data items 
associated with a SDR as a whole; 



a Network Service Module, which contains tagged data items 
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related to consumption of network capacity by a particular service 
use session; 

a Service Usage Module, which contains tagged data items relating 
to sen/ice usage; and 

a Service Pricing Module which contains tagged data items relating 
to pricing of an infocom service. 

11. A telecommunications billing system, as claimed in claim 10, characterised 
in that an SDR contains: 



one. or more, Network Usage Modules; and 
one. or more. Service Usage Modules. 

12. A telecommunications billing system, as claimed in any of claims 6 to 1 1 . 
characterised in that an SDR contains a session identifier and a sequence number 
to enable a post-processing system to recover a chronological order in which 
SDRs were produced during a service use case. 

13. A telecommunications billing system, as rJaimPd in any of claims « tc 1 2. 
characterised in that an SDR contains at least the following tagged data items: 

an identity of a customer; 

an identity of a marketing company; 

an identity of a service to which the SDR relates; 

and in that an SDR may contain one. or more of the following tagged data items 



an access form; 
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a time; 
a date; 

an identity of a user; 
a connection identity; 
an operator, 



a service provider; 
a customer price; and 



a market price. 



14. A telecommunications billing system, as claimed in any of claims 10 to 13. 
10 characterised in that relationships between service modules within an SDR are 

governed by data items referred to as NSM/SUM correlators and SUM/SPM 
correlators, and in that these data items have unique values within an SDR. 



15 



A telecommunications hilling system, claimed in any pr&viou* dsim. 
characterised in that said billing system includes one. or more, price lists, and in 
1 5 that said pricing system is adapted to implement price list definitions, identify price 

lists to which an SDR relates and thereby produce priced SDRs. 

1 6. A telecommunications billing system, as claimed in claim 1 5. characterised 
in that said pricing scheduler means includes said pricing system and is adapted 
to receive SDRs. analyse SDRs and identify price lists appropriate to an SDR. 

20 1 7. A telecommunications billing system, as claimed in claim 16. characterised 

in that said pricing scheduler means is service independent, and in that anything 
which is service, customer, or market unique, is incorporated in price lists. 



t 
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18. A telecommunications billing system, as claimed in either claim 16 or claim 
17. characterised in that each infocom service has a unique pricing schedu.er 
means associated therewith. 

19. A telecommunications billing system, as claimed in any previous claim 
characterised in that said pricing scheduler means Is adapted to assemble a 
plurality of SDRs before said SDRs are priced. 

20. A telecommunications billing system, as claimed in any of claims 16 to 18 
characterised in that said pricing scheduler means is adapted to price individual 
SDRs. 

21. A telecommunications billing system, as claimed in any previous claim 
characterised in that customers are handled for pricing purposes, as individuai 
customers, or as members of a customer group. 

22. A telecommunications billing system, as claimed in any of claims 15 to 21 
characterised in that all price lists are based on a basic price list. 

23. A telecommunications billing system, as claimed in any of claims 1 to 1 8 
characterised in that price lists are of one of the following types: 

a base price list which is independent of customer and time of use 
of an infocom service; 

a customer group price list, applicable to a group of customers, and 

a customer unique price list applicable to a single customer. 

24 A telecommunications billing system, as claimed in claim 23. characterised 
in that price fists are either lists of prices, or algorithms/functions for calculat.no 
pnces. 



25. 



A telecommunications billing system, as claimed in any previous claim. 
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characterised in that SDRs may be generated independently of any action 
performed by a customer. 

26. A telecommunications billing system, as claimed in any of claims 4 to 25. 
characterised in that costs for a service use session are shared between different 
customers. 

27. A telecommunications billing system, as claimed in any previous claim 
characterised in that said billing system includes fault handling means adapted to 
process faulty SDRs. 

28. A telecommunications billing system, as claimed in any previous claim 
characterised in that said billing system is adapted to operate with infocom 
services having plural functions. 

29. A telecommunications billing system, as claimed in any previous claim 
characterised in that said information services network is an IN having a data 
server. 

15 30. A telecommunications billing system, as claimed in any previous claim. 

characterised in that means are provided to label an SDR as erroneous, if a pnce 
list relating to an SOR cannot be identified 

31. In a telecommunications system comprising: an information services 
network containing a plurality of service producing elements; and a communication 
services network containing a plurality of service switching elements, a signalling 
network and a transport network, said telecommunications network being adapted 
to provide infocom services to customers, a method of pricing usage of infocom 
services in a flexible manner, characterised by the steps of: 

each service producing element. (SPE). generating SDRs. 



20 



25 



collecting said SDRs at a handling means, said SDRs mcli^ng a 
Service Usage Module; 
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associating each Service Usage Module with a price iist; and 

determining a price to be associated with each Service Usage 
Module and adding said price to the SDR. containing said Service 
Usage Module, in the form of a Service Pricing Module. 

32. A method, as claimed in daim 31 , characterised by returning priced SDRs 
to a handler means. 

33. A method, as claimed in daim 32. characterised by transmitting priced 
SDRs to a SDR archive means and storing said priced SORs therein until collected 
by a post processing system. 

34 A method, as claimed in claim 33, characterised by said post processing 
system being an invoicing system. 

35. A method, as daimed in any of daims 31 to 34, characterised by a service 
use session generating one, or more SDRs. 

36. A method, as claimed in any of daims 31 to 34. characterised by adding 
Service Pridng Modules to SDRs, only after an SDR has been priced. 

37. A method; as daimed in any of daims 31 to 34. characterised by each SDR 
being a collection of tagged data items describing a service use session. 

38. A method, as daimed in daim 37. characterised by an SDR's size and 
content varying in accordance with an infocom service to which it relates. 

39. A method, as claimed in either claim 37, or claim 38. characterised by 
encoding tagged data items in an SDR according to the BER for ASN.1. 

40. A method, as daimed in any of daims 37 to 39. characterised by grouping 
related tagged data .terns in an SDR into sen/ice modules. 
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41. A method, as claimed in claim 40, characterised by grouping a particular 
set of related tagged data items in an SDR into one of the following four types of 
service module: 



a Service Header Module, which contains tagged data items 
associated with SDR as a whole; 

a Network Service Module, which contains tagged data items 
related to consumption of network capacity by a particular service 
use session; 

a Service Usage Module, which contains tagged data items relating 
to sen/ice usage; and 

a Service Pricing Module which contains tagged data items relating 
to pricing of infocom service. 

42. A method, as claimed in claim 41, characterised by an SDR containing: 

one, or more. Network Usage Modules; and 
one. or more, Service Usage Mndubc. 

43. A method, as claimed in any of claims 36 to 41 , characterised by an SDR 
containing a session identifier and a sequence number to enable a post- 
processing systems to recover a chronological order in which SDRs were 
produced during a service usage case. 

44. A method, as claimed in any of claims 36 to 42. characterised by an SDR 
containing at least tre following tagged data items: 



an icsntity of a customer; 



an identity of a marketing company; 
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an identity of a service to which the SDR relates;; 
and by an SDR containing one, or more, of the following tagged data items 
an access form; 
a time; 
a date; 

an identity of a user; 
a connection identity; 
an operator; 
a service provider; 
a customer price; and 
a market price. 

45. A method, as claimed in any of claims 40 to 43. characterised by an SDR 
including data items referred to as NSM/SUM correlators and SUM/SPM 
correlators which govern relationships between service modules in the SDR. and 
by the values of these data items being unique within an SDR. 

46. A method, as claimed in any of claims 31 to 45. characterised by said 
billing system including one, or more, price lists, and by said billing system being 
adapted to implement price list definitions, identify price lists to which an SDR 
relates and thereby produce priced SDRs. 

47. A method, as claimed in claim 46. characterised by a pricing scheduler 
means being adapted to receive SDRs, analyse SDRs and identify price lists 
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appropriate to an SDR. 

48. A method, as claimed in of claims 31 to 47, characterised by assembling 
a plurality of SDRs before pricing them. 

49. A method, as claimed in of claims 46 to 48, characterised by basing all 
price lists on a basic price list. 

50. A method, as claimed in claim 49. characterised by price lists being one of 
the following types: 

a base price list which is independent of customer and time of use 
of sen/ice); 

a customer group price list, applicable to a group of customers: and 
a customer unique price list applicable to a single customer 

51 . A method, as claimed in claim 50, characterised by price lists being either 
lists of prices, or algorithms/functions for calculating prices. 

52. A telerommunicati5r,3 system, charaaeristU in that s<«a 
telecommunications system includes a billing system, as claimed in any one of 
claims 1 to 30. or in that said telecommunications system is adapted to price 
telecommunications service and network usage using the method claimed in any 
one of claims 31 to 51 . 

53. A telecommunications system, as claimed in daim 52. characterised in that 
said post-processing system is an invoice system. 

54. A telecommunications system, as claimed in either claim 52, or claim 53 
characterised in that SDRs are moved from service producing element, to pacing 
scheduler means, to an invoicing system. 
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55. A telecommunications system as claimed in any of claims 52 to 54. 
characterised in that SDRs may be used for any of the following functions: 

billing, both inside and outside a telecommunication operator's own 
organisation; 

consolidated billing; 

production of reports and statistics; 

quality assurance; and 

service management, including identification of fraud, churning, 
abnormal traffic loads, failure rates and technical malfunctions. 

56. A telecommunications system as claimed in any of claims 52 to 55. 
characterised in that post-processing systems, requiring access to information 
contained in SDRs. subscribe to said handler means. 

57. A telecommunications system, as claimed in any of claims 52 to 56. 
characterised in that said system has a single invoice printing function. 

58. A telecommunications system, as claimed in any of claims 52 to 57. 
characterised in that said pricing scheduler means handle pricing of traffic rates 
and service events, and in that pricing related to periodical charges, subscription 
charges and discounts are handled by post processing systems. 

59. A telecommunications system, as claimed in any of claims 52 to 58. 
characterised in that each post-processing system subscribes to SDRs from one. 
or more infocom services, and/or to selected data items from within an SDR. 

60. A telecommunications system, as claimed in any one of cia.ms 52 to 59. 
characterised in that post-processing systems collect SDRs. at oredeterm.ned 
intervals from a SDR archive, and/or in that post-processing systems are alerted 
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when SDRs are available for collection in a SDR archive. 

61. A telecommunications system, as claimed in any one of claims 52 to 60. 
characterised in that at least some infocom sen/ice producing elements issue 
SDRs as a request for pricing information, which SDRs are passed to pricing 
scheduler means, priced and returned to said service producing elements. 

62. A telecommunications system, as claimed in any of claims 56 to 61. 
characterised in that SDRs without a subscribing post-processing entity are 
discarded while SDRs having a subscribing post-processing entity are retained for 
a period of time in a SDR archive. 
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pays for service usage 



pays for service usage 
receives payment for 
service provision 



receives payment for 
service marketing 



receives payment for 
service production 



receives payment for 
network provision 




provisioning cost + 
marketing cost + 
production cost + 
network cost 



provisioning cost + 
marketing cost + 
production cost + 
network cost 



provisioning cost + 
marketing cost + 
production cost + 
network cost 



provisioning cost - 
marketing cost + 
production cost + 
network cost 



FIGURE 16 
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